Processing network nodes in current optical networks employing CMOS technology are limited by the speeds of this technology, which are well below currently available speeds of transmitting data over fibre optic links in such networks. In addition, at a network processing node, data may come from several different sources, on different connections and at different line clocks. However, at the node, all data must be processed at a local system clock. Accordingly, pointer processor systems are used within processing network nodes to perform timing adjustments on incoming data, by converting the incoming data from a line clock domain to a local system clock domain or ‘shelf-time’ domain.
In order to be able to handle large data frames, pointer processors usually comprise several integrated circuits. In turn, each integrated circuit may comprise a plurality of processing strips, with each processing strip having a limited data processing capacity. A known pointer processor design for SONET (Synchronous Optical Network) or SDH (Synchronous Digital Hierarchy) type data frames is structured on STS (Synchronous Transmission Signal)-n level pointer processing strips, which are capable of processing the equivalent of n STS-1 building blocks from a SONET/SDH frame.
It is often desirable to be able to carry frames comprising large payloads, such as concatenated STS-Nc frames across pointer processing nodes. This implies that for N greater than n, concatenated payloads must be carried across several STS-n level pointer processing strips and possibly even across several chips, when the number of STS-n level pointer processing strips on a single chip is insufficient for the STS-Nc, when N is a large number. A SONET/SDH STS-Nc concatenated frame is built from N STS-1 building blocks pasted together, but information about the beginning of the SPE is kept only in the pointer bytes, H1and H2, of the leading STS-1 block in the concatenation. In other words, only the leading STS-1 block in a concatenation comprises valid pointer information within its H1 and H2 bytes, whereas the H1 and H2 bytes of the trailing STS-1 blocks of the concatenation contain only a concatenation indication. On the other hand, in processing a SONET/SDH frame on a pointer processing strip, the strip must have valid pointer information for all the STS-1 blocks within the processed frame. It follows that in processing a concatenated payload across several pointer processing strips, strips processing trailing STS-1 blocks in the concatenation must obtain the valid pointer information from the strip processing the leading STS-1 block in the concatenation.
FIG. 1 illustrates a general scheme of passing pointer information through a pointer processing strip or SYNC block, such that it can operate properly on SONET/SDH type data frames. The pointer processing strip has a pointer interpreter side and a pointer generator side. The pointer interpreter side, working in the line clock domain, receives the incoming data frames on the ‘Data-in’ line, interprets their overhead and writes (W) the payload in an Elastic Store. The pointer generator side, working in the system or shelf clock domain, reads (R) the payload from the Elastic Store and forms new SONET/SDH or other type frames to be passed further to the processing node on the ‘Data-out’ line. The generation of frames by the pointer generator side is based on a SYNC 8K signal, which is an 8 kHz reference indicating the phase of the frame to be formed. The writing and reading of the payload to and from the elastic store, respectively, must be done based on corresponding valid pointer information. In addition, due to the format of the SONET and SDH type frames, valid pointer information on either side of the pointer processor must be available before the reading of the H3 overhead byte, on the pointer interpreter side, or the generation of the H3 byte on the pointer generator side. This is due to the fact that the H3 byte, which follows the H1/H2 pointer bytes in the line overhead of the SONET/SDH standard, may, in the event of a negative pointer adjustment, be part of the actual SPE payload. Let A and B be ports of inputting pointer information to the pointer interpreter and the pointer generator sides, respectively, from a previous pointer processing strip, for example. Also, let A′ and B′ be corresponding ports of outputting pointer information. Considering the pointer processing of a certain frame, let t1 be a moment in time when the H3 byte is read from the incoming data and t2 be a subsequent moment in tine when the H3 byte is added to the generated frame, according to the SYNC 8K signal. According to the above, it follows that for the pointer processing strip to function properly, valid pointer information must be available at A before t1 and at B before t2. Furthermore, if this condition is met and letting Δt be the propagation delay of pointer information through the pointer processing strip, valid pointer information will be outputted at A′ on or before t1+Δt, and at B′ on or before t2+Δt.
FIG. 2 illustrates a known scheme of passing pointer information along a sequence of pointer processing strips or SYNC blocks #1, #2, #3, etc. Data come in simultaneously at all blocks on their pointer interpreter sides, through ‘Data-in’ lines. Likewise, data is generated on the ‘Data-out’ lines based on the same SYNC 8K signal running to all three blocks. Assuming that SYNC block #1 receives valid pointer information through A and B at t1 and t2, respectively, then SYNC block #2 receives the valid pointer information from SYNC block #1, at t1+Δt and t2+Δt, respectively, SYNC block #3 receives the valid pointer information at t1+2Δt and t2+2Δt, respectively, and so on In order for the SYNC blocks to operate properly, the incoming H3 bytes must be read as follows: on or after t1 on SYNC block #1, on or after t1+Δt on SYNC block #2, on or after t1+2Δt on SYNC block #3, and so on. Similar conditions apply to the outgoing H3 bytes in the generated frames. It follows that in this design, only a limited number of pointer processing strips can be used to perform pointer processing on a concatenated payload. Specifically, the number of strips that can be used is approximately equal to T/Δt, where T is the length of the critical time region during which the pointer information must be propagated. Specifically, this critical time region is defined by the time period between the moment when all the necessary pointer information on the strip is available, such as after the H1/H2 bytes of the last STS-1 leader on the strip has been read, and the moment when all the pointer information must be available on the next strip, which is the moment of processing the H3 byte of the first STS-1 block processed on that strip. In the SONET standard T is approximately 100 nanoseconds (ns). Δt is dependent on the technology and is currently of the order of several ns, depending on the capacity of the SYNC blocks. For example, one of the technologies currently owned by the assignee of this application, features a 25 ns pointer information propagation delay between STS-48 level processing strips. This implies that a concatenated payload cannot be carried across more than 4 such strips, limiting the size of the concatenation frame to an STS-192c.
In addition to the need for conveying pointer information downward from one SYNC block to the next, along a string of SYNC blocks spanning a concatenated payload, information must also be conveyed in an upward fashion. For example, when the pointer state of an STS-1 block within the concatenation is ‘AIS’ (alarm indication signal), instead of ‘V’, for valid pointer or ‘C’ for concatenation indicator, such information is transmitted to preceding STS-1 blocks. From the information that travels upward across slices as indicated by the arrows U, especially important are frame error check values such as the B3 byte data, of which computation is commonly performed within the pointer processors. In the SONET standard B3 is a path Bit Interleaved Parity-8 (BIP-8) byte. The value of a B3 byte in a given frame is calculated by XOR-ing the SPE bytes of the given frame starting with the J1 byte. The calculated B3 value for the given frame must be checked against a transmitted B3 value for the given frame, which is located within the frame following the given frame in the transmission.
For a concatenated frame, the B3 value for the entire frame is kept in the B3 byte position of the leading STS-1 block in the concatenation and it is also calculated through an XOR operation over all SPE bytes in the frame. This calculation can be accomplished by XOR-ing the B3 values of all the STS-1 blocks in the concatenation. Accordingly, when a concatenation is split across several pointer processing strips, the B3 byte data must be sent upwards from strip to strip, until the strip containing the leading STS-1 block of the concatenation is reached.